Проект обліку користувацьких рахунків для інтернет-провайдерів на базі OS FreeBSD з застосуванням програми «Billing ISP »
Курсовий проект виконав студент Іванов М.М.
Санкт-Петербурзький державний МОРСЬКИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ
САНКТ-ПЕТЕРБУРГ
1999
Передпроектне обстеження об'єкта автоматизації.
Опис предметної області розв'язуваної задачі.
У теперішній час багато хто (ISP) інтернет сервіс провайдерів вирішують проблему обліку користувацьких рахунків, і проблему контролю трафіку шляхом написання нових додатків, що часто призводить до частих збоїв даного ПЗ, і відповідно не виправдовує вкладені в нього кошти. Крім того, такі продукти не здатні обслуговувати велику кількість призначених для користувача рахунків і представляти всю оброблену інформацію в компактній, зручною для роботи і аналізу формі. Більшість пропонованих в даний час систем білінгу, тобто систем обліку відпрацьованого "он-лайнового" часу користувачами Інтернет-провайдера (ISP) засновано, як правило, на аналізі стандартних лог-файлів таких опіраціонних систем, як SCO Unix, SunOS, HpOS, AIX, IRIX раз на добу, в тиждень, в місяць і т.д. У той час як пропонована система білінгу основаная принципово іншу ідею, що полягає в контролі за кожною сесією користувача окремо в реальному масштабі часу. Що дозволяє значно знизити час на обробку біллінг-інженером статистики роботи кожного користувача або групи, знизити трудомісткість занесення платежів користувачів на особові рахунки (базу даних цієї програми) і відповідно дозволяє провайдерам зменшити кількість обслуговуючого персоонала, що безпосередньо відбивається на собівартості наданих послуг.
Функції предметної області, яка реалізується завдання.
Основні функціональні переваги такого підходу полягає в тому, що відстежуються і коректно відпрацьовуються, фіксуються і генеруються у звіти такі дані як:
Реєстрування з'єднання будь-якої тривалості з точністю, що дорівнює одному кванту часу (наприклад, 5 секунд). Квант часу задається системним адміністратором;
Вичерпування коштів на особовому рахунку користувача, якщо він знаходиться в даний момент у режимі "он-лайн", і примусове його відключення (ця ситуація дуже актуальна, коли ISP надає новому клієнтові "тестовий година");
Можливість завдання для кожного користувача або для груп користувачів гнучких прайс-листів з вказівкою ціни в у.о. за 1 годину "он-лайнового" часу в залежності від часу доби і дня тижня. Наприклад, є ISP, у якого вартість "денного" (з 9 ранку до 6 вечора) Інтернету - $ 1, а "вечірнього" (з 6 вечора до 9 ранку) - $ 0,6. Користувач телефонує без чверті 6-ть вечора і працює 15 хвилин за тарифом $ 1 за годину і 30 хвилин за тарифом $ 0,6 за годину (всього 45 хвилин), а з його особового рахунку, відповідно, знімається сума $ 0,25 + $ 0,3 , тобто $ 0,55;
Перехід користувача з одного прайс-листа в інший, при вичерпування коштів на особовому рахунку в першій схемі і при авансовому платежі по іншому прайс-листу без відключення користувача. Реально це означає ситуацію, коли працював користувач по одному прайс-листу, і коли у нього стали закінчуватися кошти на особовому рахунку, він зробив новий внесок, але вже по іншому (наприклад, "пільговим") прайс-листу. Потім він допрацював свій годинник за "старим" прайс-листу і спокійно почав роботу з "новому" прайсу-листу;
Віддаленим користувачам надається зручний www-інтерфейс за допомогою якого вони можуть повністю контролювати свою роботу в Інтернеті аж до кожного модемного дзвінка на вузол ISP, в тому числі, зрозуміло, вони можуть у будь-який час подивитися розмір свого особового рахунку на поточний момент (момент генерування web звіту з бази даних програми «Billing ISP».
Системний адміністратор (біллінг-інженеру) надається достатньо простий в освоєнні стандартний для Unix систем режим командного рядка, відкритість, простота і можливість "заточування" системи під свої конкретні особливості.
Основні якості і особливості пропонованої системи білінгу
Висока точність підрахунку "он-лайнового часу" відпрацьованого користувачами;
Проста інтеграція пропонованої системи в існуючу систему аутентифікації DialUp-користувачів провайдера (забігаючи вперед, хочеться відзначити, що в даний момент наша система підтримує тільки схеми TACACS + і pppd);
Можливість розгортання пропонованої системи паралельно з уже існуючою системою білінгу провайдера для тестування і налагодження з метою остаточного запуску в експлуатацію;
Автоматичне отримання щоденних (щотижневих, щомісячних) звітів відпрацьованих годин і їх вартості за різними групами клієнтів (наприклад, "основний тариф", "пільговий тариф", "бартер", "халява");
Можливість підключення SQL-сервера для генерації більш гнучкої системи статистик за допомогою SQL-запитів;
Мінімальні вимоги до апаратних ресурсів сервера білінгу (пропонована система може функціонувати навіть без SQL-сервера). Однак, www-сервер (Apache) все-таки слід встановити для того, щоб вилучені користувачі мали доступ до своєї статистики через звичний www-інтерфейс;
Своєчасне оповіщення користувача і системного адміністратора через e-mail про те, що розмір особового рахунку користувача наближається до кінця;
Гнучке ведення прайс-листів по групах користувачів, їх швидка та нескладна модифікація (наприклад, установка "святкового тарифу" коли "народне гуляння" випадає на середину тижня);
Можливість віддаленого адміністрування користувачів
PS У вище викладеному тексті застосовуються деякі професійні терміни відносяться до різних клонам Unix систем, а також до общесистемному професійному ПО такі як: (демон, Apache, pppd, домашній каталог користувача, ядро, сервер біллінгу, лог-файл, користувач, www-інтерфейс , SQL і т.д.), які потребують додаткових коментарів. Описи даних термінів можна порівняти з повноцінним книжковим виданням, внаслідок чого воно тут не присутня. Короткі пояснення можна отримати у укладача даної курсової роботи.
Організаційно-економічна сутність задачі.
Використання даного комплексу програмного забезпечення дозволить невеликому інтерні-провайдеру значно знизити собівартість послуг з комутаційного підключенню своїх абонентів, а також надати їм зручну систему тарифних планів, тестових підключень, систему аналізу і моніторингу власних рахунків та статистики підключень, що природно сприяє зростанню клієнтської бази і збільшенню прибутку нашого ISP.
Також варто відзначити, що основна економія коштів відбувається за рахунок використання абсолютно безкоштовного програмного забезпечення, а саме операційної системи FreeBSD і системи обліку «Billing ISP», які поширюються з відкритим вихідним кодом за ліцензією GNU і не мають обмежень на кількість екземплярів і т.д . Наявність вихідного коду даних продуктів дає можливість адаптації їх під вже існуючі бухгалтерські програми і системи обліку. Також значна економія відбувається за рахунок невеликого числа технічного персоналу, який експлуатує дану систему. За персоналу можна відзначити, що управляти цією системою можуть фахівці низької кваліфікації, тобто саме система «BillinISP» не вимагає поглибленого знання Unix подібних опіраціонних систем, мережевих технологій і складного мережевого обладнання такого як CISCO, з чого випливає, що з / п такого працівника буде відносно не велика. У теж час середня з / п сертифікованого фахівця коливається від 500 $ -1500 $. Природно, що для підтримки системи в актуальному стані такі працівники необхідні, але за рахунок застосування даної схеми їх число можна значно зменшити без втрати якості обслуговування клієнтів.
Для довідки деякі комерційні операційні системи можуть досягати вартості 5000 $, при це з обмеженим числом установок і з обмеженим числом користувачів плюс до цього близько 2000-3000 $ може коштувати яка не будь посередня білінгова система.
З усього вище сказаного видно, що при застосуванні даного програмного забезпечення інтернет-провайдери отримують істотну вигоду.
Розробка інформаційного забезпечення задачі.
Опис вхідної інформації.
Основним вхідним документом, з яким взаємодіє розглянута білінгова система це копія платіжного доручення користувача ISP. При реєстрації клієнта провайдер пропонує йому вибрати встановлений тариф (прайс-лист) на послуги комутованого підключення на певний (тарифом) час, за яким клієнт буде перераховувати встановлену грошову суму. Після реєстрації та передоплати послуг нашого ISP на рахунок (у домашній каталог користувача копіюються певний набір файлів див. нижче) користувача надходить певна прайс-листом сума, яка в процесі роботи користувача в інтернеті зменшується через певний тарифом (прайс-листом) квант на певну суму . Відповідно всі, що робить одна частина програми білінгу інша її частина фіксує все в базі даних і в тому ж власному каталозі користувача в окремий лог-файл на підставі, якого і генеруються звіти користувачеві та адміністратору. Також до вхідної інформації можна віднести: відрахування з користувальницького рахунку, проведений час в інтернеті, час з'єднання (реєстрації у системі). На підставі викладеної вище інформації допоміжний модуль програми білінгу може надавати докладну статістікуего рахунку користувача, як адміністраторові так і самому клієнту ISP.
Файл завдання прайс-листа (тарифної схеми) - account.conf
#
#
# Приклад файлу account.conf (. Account.conf). # Лідируючі прогалини, порожні рядки,
# Рядки, що починаються з символу "#" ігноруються.
# Обробляються лише рядки, що починаються з ключового
# Слова "price:". Кількість рядків "price" неограченно.
# Формат прайс-листа (тарифної схеми) -
# Price: День_неделі, час_начала-час_окончанія $ стоімость_в_у.е.
# Що відповідає проміжку часу
# Час_начала :00-час_окончанія: 59
# Якщо при вказівці тимчасові діапазони перетинаються, то вартість
# Години приймається остання.
# Основна тарифна схема. # Ціна: у будні дні з 10:00-18:00 - $ 1
# В інший час - $ 0,6
#
#
comment: Поле_comment_будет_автоматически_выводиться_при_запуске
comment: демома_в_режиме_получения_сведений_о_размере_лицевого
comment: счета_пользователя._Удобно_использовать_для_задания_комментарий
comment: к_прайс_лісту.
commenth:
commenth: Поле_commenth_виводітся, _еслі_размер_ліцевого_счета
commenth: выдается_в_html_формате._Пробелы_должны
commenth: заменяться_на_подчеркивания._Количество_строк_comment_и
commenth: commenth_не_огранічено, _однако_суммарная_длина_каждой_не
commenth: не_должна_превышать_1000_символов.
price: Monday, 0-9 $ 0.6
price: Monday, 10-17 $ 1
price: Monday, 18-23 $ 0,6
price: Tuesday, 0-9 $ 0.6
price: Tuesday, 10-17 $ 1
price: Tuesday, 18-23 $ 0,6
price: Wednesday, 0-9 $ 0.6
price: Wednesday, 10-17 $ 1
price: Wednesday, 18-23 $ 0,6
price: Thursday, 0-9 $ 0.6
price: Thursday, 10-17 $ 1
price: Thursday, 18-23 $ 0,6
price: Friday, 0-9 $ 0.6
price: Friday, 10-17 $ 1
price: Friday, 18-23 $ 0,6
price: Saturday, 0-23 $ 0.6
price: Sunday, 0-23 $ 0.6
Опис файлів у домашньому каталозі користувача з "білінгової інформацією"
. Pay - інформація про нарахування (історія нарахувань) на особовий рахунок користувача умовних одиниць або $. Файл має формат види:
#
#
# Платежі клієнта ivan
#
#
1999/02/27 13:00:01 Add pay | 10.5
1999/03/15 15:12:00 Add pay | 23
1999/05/05 12:30:40 Add pay | 6.5
Як видно, цей файл має два поля довільної довжини розділені символом "|". Перше (ліве) поле містить коментар або, іншими словами, обгрунтування для другого (правого) поля, в якому міститься число з плаваючою точкою, що визначає вартість транзакції, тобто вартість білінгової інформації. Основна і єдина одиниця виміру білінгової інформації - умовна одиниця або $. Якщо наведений вище файл міститься в домашньому каталозі користувача ivan, то, підсумувавши друге (праве) поле, можна з'ясувати, що загальний розмір нарахувань на особовий рахунок (або платежів) клієнта ivan дорівнює 40 умовним одиницям. Відкривши цей файл, системний адміністратор або користувач ivan може не тільки дізнатися скільки взагалі було нараховано на даний особовий рахунок, але і те, коли (ким) це було зроблено (забігаючи вперед, хочеться відзначити, що подібний спосіб зберігання білінгової інформації в звичайних текстових файлах , тобто "дата, обгрунтування операції | розмір", є основним для пропонованої системи). Додавати або змінювати інформацію у файлах. Pay повинен тільки системний адміністратор. Робити це можна як з командного рядка, так і через веб-інтерфейс;
. Weekly - інформація про відрахування (історія відрахувань) з особового рахунку користувача в умовних одиницях за фактичну роботу за поточний тиждень по кожному з'єднанню (по кожній наданій послузі). Формат файлу аналогічний формату файлу. Pay
#
#
# Робота клієнта ivan за поточний тиждень
#
#
1999/05/18 13:00:01 Time elapsed = 40 sec., Cost | 0.052
1999/05/19 15:12:00 Time elapsed = 1200 sec., Cost | 0.156
1999/05/19 16:30:40 Time elapsed = 75 sec., Cost | 0.101
Запис у файл. Weekly робить демон після закінчення з'єднання. У наведеному вище фрагменті файлу. Weekly в першому полі міститься наступна інформація: дата закінчення з'єднання (YYYY / MM / DD), Врен закінчення з'єднання (HH: MM: SS), тривалість з'єднання в секундах (Time elapsed). У другому полі файлу. Weekly, відокремленого символом "|" міститься вартість транзакції (вартість з'єднання, вартість фактично наданої послуги в умовних одиницях);
. Work - інформація про відрахування (історія відрахувань) з особового рахунку користувача по за цілі тижні в сумі. У кінці кожного тижня друге поле файлу. Weekly підсумовується і підсумкова сума заноситься у файл. Work.
1999/05/18 1999/05/25 cost | 5.011
1999/05/26 1999/06/01 cost | 2.133
Файли. Weekly в домашніх каталогах користувачів "розбухають" внаслідок того, що там протоколюється кожне з'єднання. З іншого боку, як показує практика, більшості користувачів цікавий лише докладний звіт використання машинного часу за поточну і минулий тиждень, тому інформація, накопичена у файлах. Weekly повинна "компресувати". Якщо ж користувачеві потрібно надати докладний звіт за роботу двох-(трьох-, чотирьох-і т.д.) тижневої давності (що трапляється не так часто), то цю інформацію системний адміністратор може "витягнути" з SQL-бази. Оновленням файлів. Work,. Weekly і. Weekly.last повинна займатися спеціальна програма w_update.pl, що запускається по крону тижні;
. Weekly.last - копія файлу. Weekly за минулий тиждень;
. Current - поточний розмір особового рахунку користувача в умовних одиницях, файл оновлюється після завершення кожної сесії даного користувача, служить для "швидкого" обчислення розміру особового рахунку користувача, наприклад, при старті нового з'єднання;
. Time - наявність такого файлу (під наявністю файлу мається на увазі файл з такою назвою будь-якої довжини, в тому числі і нульовий, доступний для читання в даний момент) сигналізує про те, що баланс особового рахунку користувача завжди позитивний. У російській мові зазвичай під цим розуміють солодке слово "халява". Зрозуміло, цей файл перш за все повинні мати, наприклад, співробітники ISP та їх найближчі родичі ;-)
. Refused - наявність такого файлу сигналізує про те, що баланс особового рахунку користувача завжди негативний, тобто доступ йому в систему тимчасово призупинено;
. Type - тип користувача (наприклад, "свій", "халява", "бартер", "гроші"). Служить для ділення користувачів на групи, за якими в подальшому генерується статистична інформація;
. Account - тип (або індекс) прайс-листа для даного користувача. Цей файл дуже зручно використовувати для завдання прайс-листа окремим групам користувачів. Ви створюєте бажаний прайс-лист і ставите його в каталог / var / statserv / etc, а користувачам в домашніх каталогах вказуєте лише посилання на нього. Якщо Ви хочете поміняти прайс-лист для деякої групи користувачів, то, Ви редагуєте прайс-лист всього в одному місці (див. нижче "Алгоритм вибору тарифної схеми для користувача при старті демона");
. Account.conf - власний прайс-лист для даного користувача. Див структуру файлу. Account.conf. Цей файл слід застосовувати в тому випадку, коли Ви хочете задати для користувача індивідуальний прайс-лист;
. Pay.next - авансовий платіж, або наступне нарахування на особовий рахунок користувача після обнулення поточного особового рахунку. Може бути використане у тому випадку, коли користувач не вичерпав поточний особовий рахунок, однак оплатив наступну послугу з раніше чи новому прайс-листа;
. Account.next - те ж, що й. Account (див. вище), але тільки для авансового платежу.
Опис вихідних документів.
У результаті роботи білінгової програми вся інформація про роботу користувач, як було сказано вище, фіксується в лог-файлах та базі даних. Це є основним базисом для генерації звітів та статистики. Вилучувані дані можуть бути представлені як структурованих таблиць, або у формі звітів по запитуваною даними. Дана інформація, також є підтвердженням того, що користувач працював в мережі на випадок претензій останнього.
Список інформації - даних, які пропонуються користувачеві і системного адміністратора (біллінг-інженеру):
Час реєстрації користувача в конкретний день
Сума, що залишилася на рахунку у користувача
Час, проведений в мережі
Статистика роботи в мережі по днях, тижнях і місяцях
Поштове повідомлення користувача і адміністратора про закінчення грошового внеску.
Загальна структурована таблиця статистики за певний період часу
При генерації вище зазначеної інформації використовуються додаткові модулі програми «Billing ISP" та системні програми Unix такі як, CGI-модулі (для звернення до баз даних та генерації HTML коду і форм або листів), Apache web server (для виводу на екран HTML коду згенерованого CGI програмою), MTA Sendmail (для відправки електронного листа користувачу про закінчення рахунку).
Опис технології та алгоритмів розв'язання задачі та їх машинна реалізація.
Опис введення в базу даних вхідної інформації.
Відмінна риса даної програми від інших варіантів даної курсової роботи, є повністю ароматична генерація і занесення в базу даних інформації за винятком створення самих рахунків користувачів. Це визначається в основному специфікою даного програмного продукту і операційного середовища, в якій він працює.
Алгоритм нарахування умовних одиниць на особовий рахунок користувача
Якщо файл. Pay в домашньому каталозі користувача, то занести розмір платежу в файл. Pay, а індекс прайс-листа у файл. Account. Перехід до пункту 3;
Обчислити поточний розмір особового рахунку користувача. Якщо він негативний або дорівнює нулю, то черговий платіж заноситься у файл. Pay, а вибраний індекс прайс-лист у файл. Account. Якщо поточний розмір особового рахунку користувача позитивний, то черговий платіж заноситься у файл. Pay.next, а вибраний індекс прайс-листа у файл. Account.next;
Обновити файл. Current з поточним розміром особового рахунку;
Занести платіж у таблицю "ПЛАТЕЖІ" бази даних (опціонально).
Алгоритм фіксації в базі статистичної інформації
Введення.
Розглянутий програмний продукт безпосередньо залежить від системних викликів операційного середовища, в якій він працює, а також і від деяких програм, наприклад PPPD (назва цього демона походить від назви протоколу з'єднання користувача і провайдера Point to Point Protocol), syslog (системна програма, яка фіксує перебування користувача в системі, а також фіксує в лог-файли повідомлення ядра ОС). У зв'язку з тим, що описи даних продуктів це тема окремої курсової роботи, даний алгоритм буде описаний поверхово.
При з'єднанні користувача до провайдера запускається програма Mgetty, яка управляє і ініціалізує роботу модему. Запуск цієї програми фіксується в системних лог-файли системи. Після її запуску вона активізує, в нашому випадки демон PPPD, який у свою чергу Прінемаемие і реєструє запити користувачів і після перевірки всього необхідного впускає чи ні в систему. Всі дії даних сервісів після з'єднання відстежує програма syslog, яка і генерує основну базу дій користувача у системі.
Billing ISP, як вже говорилося вище безпосередньо взаємодіє з PPPD перевіряючи актуальність даного підключення і у випадки вдалого входу змінює (зменшує) за певний квант часу рахунок користувача.
Також демон білінгу з моменту з'єднання користувача починає вести підрахунок часу перебування користувача з відповідною зміною в SQL базі полів.
Узагальнений алгоритм рішення задачі.
Ядром пропонованої системи є спеціально написаний демон "білінгу" (надалі просто демон), що здійснює контроль за ізрасходованнним часом і / або умовними одиницями користувача, що знаходиться в даний момент у режимі "он-лайн". Демон запускається в момент входу користувача в систему, після закінчення одного кванта часу (наприклад, 5 секунд) знімає з особового рахунку користувача вартість одного кванта відповідно до діючої в даний момент ціною, яка, до речі, може змінюватися в залежності від часу доби, а після завершення сеансу зв'язку демон припиняє свою роботу, протоколюючи інформацію про тривалість сеансу зв'язку та відпрацьованої вартості в спеціальний лог-файл у домашньому каталозі користувача і, при необхідності, в загальну SQL-базу даних. Іншими словами, окрема копія демона постійно присутня в пам'яті сервера білінгу і "стежить" за користувачем протягом усього сеансу зв'язку. Інформація про нарахування на особовий рахунок користувача і зняття з особового рахунку за фактично відпрацьований "он-лайновий" час (так звана "білінгова інформація") зберігається в домашніх каталогах користувачів у звичайних текстових файлах. Тобто для кожного користувача створюється свій набір файлів з білінгової інформацією. Відповідно, обчислення розміру особового рахунку користувача відбувається на підставі вмісту цих файлів. Таке розподілене зберігання білінгової інформації по кожному користувачеві забезпечує простоту побудови системи, а значить надійність, і надає можливість організації нескладної системи доступу до особових рахунків через www-інтерфейс. У той же час, така ж інформація, але трохи в іншому вигляді зберігається в SQL-базі, проте вона використовується виключно для генерації статистичної інформації наданої системного адміністратора.
Алгоритм виконання окремих модулів.
Алгоритм обчислення особового рахунку при вході користувача в систему
Даний алгоритм повинна реалізовувати програма, що виконує автентифікацію користувача (TACACS + або pppd) на етапі підключення його до Інтернету. У цей випадку основну роль повинен грати файл. Current, який містить уже розрахований значення розміру особового рахунку, тому що в даний момент розмір особового рахунку повинен бути отриманий практично миттєво.
Якщо файл. Refused присутній у домашньому каталозі користувача, то поточний розмір особового рахунку приймається негативним. Перехід до пункту 5;
Якщо файл. Time присутній у домашньому каталозі користувача, то поточний розмір особового рахунку приймається позитивним. Перехід до пункту 5;
Якщо файл. Current присутній у домашньому каталозі користувача, то з нього береться поточний розмір особового рахунку (файл. Current оновлюється кожного разу після завершення роботи демона). Перехід до пункту 5;
Поточний розмір особового рахунку обчислюється за формулою: "загальна сума нарахувань з файлу. Pay мінус загальна сума відрахувань з файлу. Work мінус загальна сума відрахувань з файлу. Weekly";
Якщо поточний розмір особового рахунку позитивний, доступ до системи користувачеві дозволять, в іншому випадку - забороняється.
Алгоритм вибору прайс-листа (тарифної схеми) для користувача при старті демона
Якщо в домашньому каталозі користувача знаходиться файл. Account.conf, то прайс-лист для даного користувача читається з цього файлу;
Якщо в домашньому каталозі користувача прісутсвуєт файл. Account, то з нього читається перший рядок, яка додається в слову account, до отриманої рядку додається розширення. Conf, і, таким чином файл c прайс-листом з отриманим ім'ям читається з каталогу / var / statserv / etc;
Якщо файли. Account.conf і. Account відсутні в домашньому каталозі користувача, то прайс-лист для даного користувача читається з файлу / var / statserv / etc / account.conf (прайс-лист за замовчуванням)
Дії, що виконуються демоном при старті
Аналізує командний рядок. В якості першого параметра йому передається ім'я користувача, в якості другого - NAS-порт (або пристрій, наприклад, / dev/cuaa2), в якості третьої - адреса NAS-сервера (третій параметр потрібний тільки в тому випадку коли в провайдера більше одного NAS 'a);
Вибирає прайс-лист (тарифну схему) для користувача (див. "Алгоритм вибору прайс-листа для користувача при старті демона");
Перевіряє присутність в домашньому каталозі файлу. Time, якщо він там є - зводить відповідний прапорець у змінну us.unoff = 1;
Перевіряє присутність в домашньому каталозі файлу. Refused, якщо він там є - зводить відповідний прапорець у змінну us.refused = 1;
Обчислює значення особового рахунку користувача (див. пункт 4 "Алгоритму обчислення особового рахунку при вході користувача в систему"). Навіть якщо розмір особового рахунку від'ємний, демон все одно продовжить свою роботу, оскільки після закінчення першого ж кванта часу він, при необхідності, подасть сигнал на відключення цього користувача;
Демонізується ;-);
Записує свій PID у файл з ім'ям NAS-порту в каталог / var / run (якщо у провайдера більше одного NAS'a - то необхідно модифікувати демон, щоб уникнути конфліктів в каталозі / var / run між NAS'амі);
Програмує власний таймер на заданий квант часу і входить у нескінченний цикл, вивести з якого може тільки SIGHUP.
Дії, що виконуються демоном при закінченні одного кванта часу
Оновити лічильник (у секундах) тривалість активного з'єднання, відповідно до діючого тарифу обчислити вартість одного кванта часу, оновити змінну в якій накопичується вартість поточної сесії;
Перевірити, чи присутній користувач все ще в системі - переглянути файл / var / run / utmp. Якщо користувача в системі немає, то викликати процедуру, виконувану при завершенні сесії;
Якщо користувач не вичерпав свій особовий рахунок, то чекати закінчення наступного кванта часу. В іншому випадку такі дії виникають при вичерпування коштів на особовому рахунку:
Перевірити, чи є цей використовувати "привілейованих". Для цього подивитися на прапорець us.unoff. Якщо us.unoff == 1, то чекати закінчення наступного кванта часу;
Перевірити, чи була викликана програма / var / statserv / bin / killuser, якщо так - то чекати закінчення наступного кванта часу. Справа в тому, що через особливості побудови деяких систем аутентифікації, при вичерпування коштів на особовому рахунку, фактично користувач відключається не відразу після виклику програми / var / statserv / bin / killuser, а через деякий інтервал часу;
Якщо файл. Pay.next відсутня в домашньому каталозі користувача, значить, користувача необхідно примусово відключити. Перехід до пункту 9;
Читати суму з файлу. Pay.next. Переписати її у файл. Pay. Видалити файл. Pay.next. Обчислити поточний розмір особового рахунку користувача. Якщо він негативний, то перехід до пункту 9;
Перечитати новий прайс-лист з файлу. Account.next. Видалити файл. Account.conf, якщо він присутній. Перейменувати файл. Account.next у файл. Account і чекати закінчення наступного кванта часу.
Викликати програму / var / statserv / bin / killuser з параметрами ім'я_користувача і NAS-порт, яка пошле сигнал на відключення користувача;
Дії, що виконуються демоном при завершенні сесії
При завершенні сесії сервер аутентифікації TACACS (або pppd) читає PID демона з каталогу / var / run / і посилає йому SIGHUP (можливий, також інший варіант, коли демон постійно сканує файл utmp і виконує нижче описані дії, якщо користувач "ізчез" з файлу utmp). Демон видаляє файл зі своїм PID-му з / var / run /, записує відомості про щойно завершеної сесії у файл. Weekly, оновлює файл. Current з поточним розміром особового рахунку користувача і викликає скрипт / var / statserv / bin / close_session. з параметрами ім'я_користувача, NAS-port, продолжітельность_сессіі, стоімость_сессіі.
Контрольний приклад.
Опис використання демона білінгу
Демон billing є ядром пропонованої системи обліку користувачів для ISP. Він може працювати в двох режимах - в "основному" режимі (тобто режимі демона) для контролю особового рахунку користувача в реальному масштабі часу і в "допоміжному" режимі видачі відомостей про розмір особового рахунку користувача або контролю правильності завдання тарифної схеми. Нижче приведені всі можливі ключі запуску і параметри командного рядка:
/ Var / statserv / bin / billing
Usage error: billing [-vdeashtpPrRwW] [username] [port] [nas]
-V show version and exit
-D daemonize billing
-E increase debug level in daemonize mode
-A show current price
-C show current account for sysadmin
-S show current account
-H show current account in HTML format
-T total user account
-P show pay-P show pay history
-N show pay.next-N show pay.next history
-R show work-R show work history
-W show weekly-W show weekly history
Режим демона - запуск з ключем-d. Далі слідують обов'язкові параметри - ім'я користувача, NAS-порт (порт модему) і ім'я NAS-сервера (якщо NAS-сервер у ISP один, то цей параметр вибирається довільно, проте зовсім опускати його не можна). Приклад:
/ Var / statserv / bin / billing-d jackson Async2 access.provider.net
Режим видачі відомостей про розмір особового рахунку користувача - запуск з ключем-s і єдиним параметром - ім'ям користувача. Приклад:
/ Var / statserv / bin / billing-s jackson
У даному варіанті на стандартний висновок нічого не виводиться, а "знак" лицьового рахунку відображається в коді повернення. Якщо розмір особового рахунку більше або дорівнює нулю, тобто доступ користувачеві в систему дозволений, то billing повертає число 0, якщо менше нуля, тобто доступ користувачеві в систему обмежений, то billing повертає число 1.
/ Var / statserv / bin / billing-st jackson
На стандартний висновок виводиться загальний розмір особового рахунку користувача в plain text. Див. п.4 алгоритму обчислення розміру особового рахунку користувача
/ Var / statserv / bin / billing-spt jackson
На стандартний висновок виводиться загальний розмір нарахувань на особовий рахунок користувача і його загальний розмір в plain text. Алгоритм обчислення особового рахунку той же самий. Ключ-P задає висновок історії нарахувань.
/ Var / statserv / bin / billing-c jackson
Відповідає викликом
/ Var / statserv / bin / billing-stpnrw jackson
тобто найбільш "вживаною" використання billing з точки зору системного адміністратора. Виклик billing з ключем-h, наприклад
/ Var / statserv / bin / billing-shtpnrw jackson
виводить інформацію про особовий рахунок користувача в HTML-форматі для того, щоб її можна було надавати користувачеві через www-інтерфейс;
Режим перевірки алгоритму вибору прайс-листа для користувача. Виклик:
/ Var / statserv / bin / billing-a jackson
Призначений виключно для системного адміністратора щоб контролювати правильність завдання тарифної схеми для даного користувача.